Configuration
There are two steps to configure ZEST for a Web application
- Configure WEB-INF/web.xml to specify ZEST as a filter
- Configure WEB-INF/zest.xml to specify the definitions of actions
Configure WEB-INF/web.xml
First, you have to map ZestFilter to the URL that you'd like ZEST to handle. For example, you could configure WEB-INF/web.xml
to map it to all URLs as follows.
<web-app>
<filter>
<filter-name>zest</filter-name>
<filter-class>org.zkoss.zest.sys.ZestFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>zest</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>
Configure WEB-INF/zest.xml
To map a request URI to an action, you have to provide a configuration file called WEB-INF/zest.xml
. For example, assume we have an action called foo.HelloAction
and you'd like to map it to /hello
, such that it will be invoked when the user visits http://yourwebsite.com/app-context/hello, then you could configure it as follows.
<zest>
<action path="/hello" class="foo.HelloAction" method="execute">
<result name="success">/WEB-INF/foo/Hello.jsp</result>
</action>
</zest>
where the path
attribute specifies the URI of request that this action matches. It could be a regular expression. The method
attribute specifies the name of the method to call when the action is matched. If omitted, execute
is assumed.
In additions, the result
element specifies the URI of the view to render and send to the user. As shown, it specifies /WEB-INF/foo/Hello.jsp
shall be used if the action returns "success"
after invoked. You could add any number of result
elements you want. If the name
attribute is not specified, it is the default result, i.e., it matches any result.
Then, when a user visits http://yourwebsite.com/app-context/hello (assume the application's context path is app-context
), an instance of foo.HelloAction
will be instantiated, and then foo.HelloAction.execute()
will be invoked. Finally, if execute()
returns "success"
, ZEST will forward to /WEB-INF/foo/Hello.jsp
.
In general, an action is implemented and mapped for a particular feature, and you could have as many as actions you'd like.
The class
and method
attribute and the view's URI could be an EL expression. For example, you could have ZEST to invoke different method based the request's status, such as ${request.method}
.
Version History
Version | Date | Content |
---|---|---|